home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19980901-19981211
/
000190_news@newsmaster….columbia.edu _Thu Oct 22 22:33:49 1998.msg
< prev
next >
Wrap
Internet Message Format
|
1998-12-10
|
5KB
Return-Path: <news@newsmaster.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id WAA28664
for <kermit.misc@watsun.cc.columbia.edu>; Thu, 22 Oct 1998 22:33:48 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id WAA07032
for kermit.misc@watsun; Thu, 22 Oct 1998 22:33:36 -0400 (EDT)
Path: news.columbia.edu!panix!logbridge.uoregon.edu!xmission!news.cc.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Stop automatic resetting of terminal emulation?
Message-ID: <wegLF5YIzlTM@cc.usu.edu>
Date: 22 Oct 98 18:36:41 MDT
References: <Pine.WNT.4.05.9810220906420.169-100000@neko.dental.washington.edu> <zr359kB7TU8S@cc.usu.edu> <70ofhk$e9d$1@apakabar.cc.columbia.edu>
Organization: Utah State University
Lines: 62
Xref: news.columbia.edu comp.protocols.kermit.misc:9386
In article <70ofhk$e9d$1@apakabar.cc.columbia.edu>, jaltman@watsun.cc.columbia.edu (Jeffrey Altman) writes:
> In article <zr359kB7TU8S@cc.usu.edu>, Joe Doupnik <jrd@cc.usu.edu> wrote:
> : Curious that you should bring up the topic because we had gone
> : over it recently in the project. Let me indicate the two views on the matter.
> : First is the IETF view. It says when the remote host asks repeatedly
> : for a terminal type the client is supposed to offer new kinds in each
> : response, as a negotiation process. Thus if a remote host does not understand
> : or accept one kind it asks again and the two sides run down their lists.
> : Spelling counts for everything here, and no two machines seem to agree
> : on spelling of terminal names. The RFCs do this haggle stuff.
> : The second is my view, which is the negotiation is stupid in the
> : extreme. When the client responds with a terminal type that's it, there
> : isn't more to the game. The remote host accepts or copes or rejects. The
> : reason haggling is so stupid is there is a great deal more concerning
> : terminal emulation than just the name/kind, and changing the name/kind
> : upsets all other items associated with the session. Keyboard definitions,
> : expectations by software at either end, and so on are most often tailored
> : for specific terminal kinds, and here the IETF says it's fine to negotiate
> : away that information without a word to the user. Amazing.
> : The fix, if we may use that term, is to force the terminal name
> : in the SET TCP TERM command so only one kind is permitted to be offered,
> : period.
> : Joe D.
>
> Joe:
>
> This case is not the same as the one that you and I talked about privately.
> In your case, the terminal type name "VT320" is not recognized by the host,
> a VMS system, but after the login occurs a terminal type query is sent
> by the host which then recognizes the terminal type as a VT320. This lack
> of host recognition of the Telnet Terminal Type negotiation is indeed
> caused by a failure of the host to have the same name for the terminal
> as the emulator, but because it has an alternate identification method
> things still work.
<omissions>
> Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
> The Kermit Project * Columbia University
> 612 West 115th St #716 * New York, NY * 10025
> http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org
-----------
It is the very same thing we talked about. Please notice that I am
not critisizing K95 et al, but I am blasting the IETF for letting things
progress has they have. You nicely made my point by showing that some apps
which expect a certain terminal type recognize things are not working and
they don't work either. That is proper. Now the user has the opportunity
to do something specific about the matter, rather than being deceived
by Telnet Options. Some apps don't know and then we are in difficulties
without realizing it.
Life would have been simpler if there had been both adherence to
the list of terminal names and timely expansion of the same, and vendors
who read before pressing keys. But like Unix itself, things got out of
control irreversibly.
Given the muddle my position remains: what the user selects is
what he/she expects to receive. Telnet terminal kind is only one piece
of a larger integrated sequence of actions and it cannot change its
behavior willy nilly without bad consequences.
What can be done? Well, there is a constructive alternative
available to us. One, enable both ends to deal with aliases of common
terminal names. Two, allow different terminal kinds upon permission and
control of the user. The first is readily accomplished in many cases, the
second requires user interface modification.
Joe D.